Policing is a key function normally performed at the edge of a public network where bad traffic should never be allowed to cause the violation of quality of service guarantees on good traffic. Policing of available bit rate (ABR) end systems is more challenging than for constant bit rate (CBR) or even variable bit rate (VBR). This is mainly because the allowed cell rate (ACR) for an ABR source can change with every resource management (RM) cell that returns to it and thus the ABR policer cannot simply assume static policing parameters. This is why ABR policing is usually described as dynamic. In particular, when the generic cell rate algorithm (GCRA) is used for ABR, it is called dynamic GCRA or DGCRA.
An ideal ABR DGCRA is too costly to implement, since it requires storing a potentially very large number of policing rate updates and their associated application times per ABR connection. Hence, several approximate DGCRAs have been proposed where only two delayed rate updates need to be stored per connection.
In general, a public network cannot and should not blindly trust its users. Through policing, the network ensures that bad traffic (i.e. the traffic emitted onto the network in violation of the traffic contracts between the network and the involved users) does not result in violating the network's quality of service guarantees to users submitting good traffic. Furthermore, a user who persists in violating his contract with the network may be declared as non-compliant.
Conventional generic cell rate algorithms (GCRAs) are bufferless leaky bucket algorithms which are widely accepted and used for CBR, VBR and unspecified bit rate (UBR) policing. During connection setup, the GCRA policer is provided with the connection's traffic descriptor. For CBR, that includes peak cell rate (PCR) and cell delayed variation tolerance (CDVT). For BVR, it includes PCR, sustainable cell rate (SCR), Maximum Burst Size (MBS) and CDVT. For UBR, it includes PCR and CDVT. Non-conforming cells may be CLPl-tagged (cell loss priority 1) (in the case of VBR and UBR) or discarded (in the case of CBR, VBR and UBR).
The GCRA policer simply ensures that the source rate is within the contracted traffic descriptor. ABR policing is much more challenging because of two main reasons, namely the dynamic nature of the allowed cell rate (ACR of the ABR source) which can change with every returning backward resource management (BRM) cell, and the many rules that the ABR end system is required to follow. The dynamic nature of the allowed cell rate provides a reason for why the GCRA is called dynamic, when used for ABR policing.
The main objective behind ABR policing is to identify and possibly take actions against ABR traffic/users which do not follow the reference behaviour specified by the ATM forum, so that they may not impact good traffic.
Generally, good ABR users are ones which follow the ATM Forum (ATMF) specifications and thus generate forward resource management (FRM) cells including both in-rate and out of rate cells, as specified, insert the correct values in the current cell rate (CCR) and minimum cell rate (MCR) fields of FRM cells, schedule FRM cells, BRM cells and data cells as specified, obey network feedback carried by returning BRM cells by adjusting the ACR accordingly, reduce the ACR when BRM cells do not return as required, or when used after a long period of idleness, and turn around FRM cells received after changing DIR bits.
An ideal ABR policer should monitor the RM cell flow, particularly BRM cells and emulate the expected ABR end system behaviour to determine if the end system is doing what it is supposed to do. Furthermore, the feedback delay from and to the end system must be taken into account. The ideal ABR policer, however, is too complex to build because it requires emulation of the already complex ABR source behaviour with all the processing and parameter storage required and requires storing a potentially large number of ER updates and their associated application times for each ABR connection.
The application time for a given ER is the time at which that ER becomes a policing rate and this depends on the feedback delay to the source. When the policer sees a BRM cell heading to the source with a certain ER value, it cannot simply and immediately adjust its policing rate to that ER. It must allow enough time before allowing the recently observed ER. The time which must be allowed is the time needed for the BRM cell to reach the source, the source to adjust its ACR accordingly, and the new rate to be felt at the policer.
Therefore, depending mainly on the distance between the source and the policer, a potentially large number of outstanding ER updates may have to be stored. For example, if the source is 100 kilometres away from the policer and the rate fluctuates, say between 500 Mbps and 600 Mbps on a given connection then using NRM equals 32, more than 368 ER updates and their associated application times have to be stored, which is too costly to implement. (NRM is the number of cells that the source end system is required to send between each successive RM cell.)